Dela via

Felsöka den programvarudefinierade nätverksstacken för Windows Server

Den här guiden undersöker vanliga SDN-fel (Software Defined Networking) och felscenarier och beskriver ett felsökningsarbetsflöde som använder tillgängliga diagnostikverktyg. Mer information om SDN finns i Programvarudefinierade nätverk.

Gäller för: Windows Server 2022, Windows Server 2019, Windows Server 2016 och Azure Stack HCI, version 21H2 och 20H2

Feltyper

Följande lista representerar den klass av problem som oftast visas med Hyper-V Network Virtualization (HNVv1) i Windows Server 2012 R2 från produktionsdistributioner på marknaden och sammanfaller på många sätt med samma typer av problem som visas i Windows Server 2016 HNVv2 med den nya SDN-stacken (Software Defined Network).

De flesta fel kan klassificeras i en liten uppsättning klasser:

  • Ogiltig konfiguration eller konfiguration som inte stöds

    En användare anropar NorthBound-API:et felaktigt eller med en ogiltig princip.

  • Fel i policytillämpning

    Policyn från Network Controller levererades inte till en Hyper-V-värd, var fördröjd, eller inte uppdaterad för alla Hyper-V-värdar (till exempel efter en Live Migration).

  • Konfigurationsavvikelse eller programfel

    Problem med datasökväg som resulterar i borttagna paket.

  • Externt fel som rör NIC-maskinvara/drivrutiner eller underläggsnätverksinfrastrukturen

    Felaktig uppgiftsavlastning (till exempel VMQ) eller felkonfigurerad underläggsnätverksinfrastruktur (till exempel MTU)

    Den här felsökningsguiden undersöker var och en av dessa felkategorier och rekommenderar metodtips och diagnostikverktyg som är tillgängliga för att identifiera och åtgärda felet.

Diagnosverktyg

Innan vi diskuterar felsökningsarbetsflödena för var och en av dessa typer av fel ska vi undersöka de tillgängliga diagnostikverktygen.

Om du vill använda diagnostikverktygen för nätverksstyrenheten (kontrollsökväg) måste du först installera RSAT-NetworkController funktionen och importera modulen NetworkControllerDiagnostics :

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

Om du vill använda diagnostikverktygen för HNV-diagnostik (datasökväg) måste du importera modulen HNVDiagnostics :

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

Diagnostik för nätverksstyrenhet

Dessa cmdletar dokumenteras på TechNet i cmdleten Diagnostik för nätverksstyrenhet. De hjälper till att identifiera problem med nätverkspolicy-konsistens i kontrollvägen mellan nätverksstyrenhetsnoder och mellan nätverksstyrenheten och NC-värdagenterna som körs på Hyper-V-värdar.

Debug-ServiceFabricNodeStatus och Get-NetworkControllerReplica cmdletarna måste köras från en av de virtuella datorerna för nätverksstyrenhetens nod. Alla andra NC Diagnostic-cmdletar kan köras från valfri värd, som har anslutning till nätverksstyrenheten och finns i antingen säkerhetsgruppen För hantering av nätverksstyrenhet (Kerberos) eller har åtkomst till X.509-certifikatet för hantering av nätverksstyrenheten.

Hyper-V värddiagnostik

Dessa cmdlets dokumenteras på TechNet i Hyper-V Network Virtualization (HNV) Diagnostics cmdlet. De hjälper dig att identifiera problem i datasökvägen mellan virtuella klientdatorer (öst/väst) och inkommande trafik via en SLB VIP (nord/syd).

Debug-VirtualMachineQueueOperation, Get-CustomerRoute, Get-PACAMapping, Get-ProviderAddress, Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortId, och Test-EncapOverheadSettings är alla lokala tester som kan köras från valfri Hyper-V värd. De andra cmdletarna anropar datasökvägstester via nätverksstyrenheten och behöver därför åtkomst till nätverksstyrenheten enligt beskrivningen tidigare.

GitHub

Microsoft/SDN GitHub-lagringsplatsen har många exempelskript och arbetsflöden som bygger på dessa in-box-cmdletar. I synnerhet finns diagnostikskript i mappen Diagnostik . Hjälp oss att bidra till dessa skript genom att skicka pull-begäranden.

Felsöka arbetsflöden och guider

[Värd] Kontrollera systemets tillstånd

Det finns en inbäddad resurs med namnet Configuration State i flera av nätverksstyrenhetsresurserna. Konfigurationsstatus ger information om systemhälsa, inklusive överensstämmelsen mellan nätverksstyrenhetens konfiguration och det faktiska (körs) tillståndet på Hyper-V-värdarna.

Kontrollera konfigurationstillståndet genom att köra följande cmdlet från valfri Hyper-V värd med anslutning till nätverksstyrenheten.

Anmärkning

Värdet för parametern NetworkController ska antingen vara FQDN- eller IP-adressen baserat på ämnesnamnet för X.509-certifikatet >som skapats för nätverksstyrenheten.

Parametern Credential behöver bara anges om nätverksstyrenheten använder Kerberos-autentisering (vanligtvis i VMM-distributioner). Autentiseringsuppgifterna måste vara för en användare som finns i säkerhetsgruppen för nätverksstyrenhetshantering.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

Meddelandet Konfigurationstillstånd liknar följande exempel:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

Anmärkning

Det finns en bugg i systemet där nätverksgränssnittsresurserna för SLB Mux Transit VM NIC är i ett feltillstånd med felet "Virtuell växel – Värden är inte ansluten till styrenheten". Det här felet kan ignoreras på ett säkert sätt om IP-konfigurationen i VM NIC-resursen är inställd på en IP-adress från det logiska överföringsnätverkets IP-pool.

Det finns en andra bugg i systemet där nätverksgränssnittsresurserna för gateway-HNV-providerns virtuella nätverkskort är i ett feltillstånd med felet "Virtuell växel – PortBlocked". Det här felet kan också ignoreras på ett säkert sätt om IP-konfigurationen i VM NIC-resursen är inställd på null (avsiktligt).

I följande tabell visas listan över felkoder, meddelanden och uppföljningsåtgärder som ska utföras baserat på det konfigurationstillstånd som observerats.

Kod Message Åtgärd
Okänd Okänt fel
Värd ej nåbar Värddatorn kan inte nås Kontrollera nätverksanslutningen för hantering mellan nätverksstyrenhet och värd
PAIpAddressExhausted PA IP-adresserna är uttömda Öka HNV-providerns logiska undernäts IP-poolstorlek
PA Mac-adresser slut. PA Mac-adresserna är uttömda Öka Mac-poolintervallet
PA-adresskonfigurationsfel Det gick inte att konfigurera PA-adresser till värddatorn Kontrollera nätverksanslutningen för hantering mellan nätverksstyrenheten och värden.
CertifikatInteBetrodd Certifikatet är inte förtrott Åtgärda de certifikat som används för kommunikation med värddatorn.
IntygEjAuktoriserat Certifikatet är inte auktoriserat Åtgärda de certifikat som används för kommunikation med värddatorn.
PolicyKonfigurationsfelPåVfp Det gick inte att konfigurera VFP-principer Det här är ett körningsfel. Inga definitiva lösningar. Samla in loggar.
Policykonfigurationsfel Det gick inte att överföra policys till värdarna på grund av kommunikationsfel eller andra problem med NetworkController. Inga konkreta åtgärder. Detta beror på fel i måltillståndsbearbetningen i nätverksstyrenhetsmodulerna. Samla in loggar.
HostNotConnectedToController Värden är ännu inte ansluten till nätverksstyrenheten Portprofilen tillämpas inte på värden, eller så kan värden inte nås från nätverkskontrollen. Kontrollera att HostID-registernyckeln matchar instans-ID:t för serverresursen.
FleraVfpAktiveradeBrytare Det finns flera VFp-aktiverade växlar på värdmaskinen Ta bort en av växlarna eftersom värdagenten för nätverksstyrenheten endast stöder en vSwitch med VFP-tillägget aktiverat.
Policykonfigurationsfel Det gick inte att push-överföra VNet-principer för ett VmNic på grund av certifikatfel eller anslutningsfel Kontrollera om rätt certifikat har distribuerats (certifikatsubjektets namn måste matcha värdens FQDN). Kontrollera även värdanslutningen med nätverksstyrenheten.
Policykonfigurationsfel Det gick inte att push-överföra vSwitch-principer för ett VmNic på grund av certifikatfel eller anslutningsfel Kontrollera om rätt certifikat har distribuerats (certifikatmottagarens namn måste matcha värdens FQDN). Kontrollera även värdanslutningen med nätverksstyrenheten.
Policykonfigurationsfel Det gick inte att push-överföra brandväggsprinciper för ett VmNic på grund av certifikatfel eller anslutningsfel Kontrollera om rätt certifikat har distribuerats (certifikatmottagarens namn måste matcha värdens FQDN). Kontrollera även värdanslutningen med nätverksstyrenheten.
Distribuerad routerkonfigurationsfel Det gick inte att konfigurera inställningarna för distribuerad router på värd-vNic TCPIP-stackfel. Kan kräva att PA- och DR-värdarnas vNICs rensas på servern där felet rapporterades.
DHCP-Adresseallokeringsfel DHCP-adressallokering misslyckades för ett VMNic Kontrollera om det statiska IP-adressattributet har konfigurerats för NIC-resursen.
CertifikatEjBetrodd
CertifikatEjAuktoriserat		 Det gick inte att ansluta till Mux på grund av nätverks- eller certifikatfel Kontrollera den numeriska koden i felmeddelandekoden: detta motsvarar winsock-felkoden. Certifikatfel är detaljerade (certifikatet kan till exempel inte verifieras, certifikatet har inte auktoriserats osv.).
Värd ej nåbar MUX är ohälsosam (det vanligaste fallet är att BGPRouter är frånkopplad) BGP-peer på BGP virtual machine i RRAS eller Top-of-Rack (ToR)-växeln kan inte nås eller upprättar inte anslutning framgångsrikt. Kontrollera BGP-inställningarna för både Software Load Balancer Multiplexer-resursen och BGP-peer (ToR eller den virtuella RRAS-datorn).
HostNotConnectedToController SLB-värdagenten är inte ansluten Kontrollera att SLB Host Agent-tjänsten är igång. För att ta reda på varför SLBM (NC) avvisade certifikatet som presenterades av värdagenten, se SLB-värdagentloggar (automatisk körning). Loggarna visar nyanserad information om körtillståndet.
PortBlockerad VFP-porten blockeras på grund av brist på VNET/ACL-principer Kontrollera om det finns andra fel, vilket kan leda till att principerna inte har konfigurerats.
Överbelastad Lastbalanserarens MUX är överbelastad Prestandaproblem med MUX.
RoutePublicationFailure MUX för lastbalanserare är inte ansluten till en BGP-router Kontrollera om MUX har anslutning till BGP-routrarna och att BGP-peering har konfigurerats korrekt.
VirtuellServerOnåbar MUX för lastbalanserare är inte ansluten till SLB Manager Kontrollera anslutningen mellan SLBM och MUX.
QoS-konfigurationsfel Det gick inte att konfigurera QOS-principer Se om det finns tillräckligt med bandbredd för alla virtuella datorer om QOS-reservation används.

Kontrollera nätverksanslutningen mellan nätverkskontrollen och Hyper-V-värd (NC-värdagenttjänsten)

Kör följande netstat kommando för att verifiera att det finns tre ESTABLISHED anslutningar mellan NC-värdagenten och nätverkskontrollnoderna och en LISTENING socket på Hyper-V-värden.

  • Lyssnar på TCP-port 6640 på Hyper-V-värd (NC Host Agent-tjänst)
  • Två etablerade anslutningar från Hyper-V värd-IP på port 6640 till NC-nod-IP på tillfälliga portar (> 32000)
  • En upprättad anslutning från Hyper-V värd-IP på en tillfällig port till nätverksstyrenhetens REST IP på port 6640

Anmärkning

Det kan bara finnas två etablerade anslutningar på en Hyper-V värd om det inte finns några virtuella klientdatorer som distribuerats på den aktuella värden.

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

Kontrollera värdagenttjänster

Nätverksstyrenheten kommunicerar med två värdagenttjänster på Hyper-V värdar: SLB Host Agent och NC Host Agent. Det är möjligt att en eller båda tjänsterna inte körs. Kontrollera deras tillstånd och starta om, om de inte körs.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Kontrollera nätverksstyrenhetens hälsotillstånd

Om det inte finns tre ESTABLISHED anslutningar eller om nätverksstyrenheten inte svarar kontrollerar du att alla noder och tjänstmoduler är igång med hjälp av följande cmdletar.

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

Nätverksstyrenhetstjänstmodulerna är:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

Kontrollera att ReplicaStatus är Ready och HealthState är Ok.

I en produktionsdistribution är med en nätverksstyrenhet med flera noder kan du också kontrollera vilken nod varje tjänst är primär på och dess enskilda replikstatus.

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

Kontrollera att replikstatusen är klar för varje tjänst.

Sök efter motsvarande HostID:n och certifikat mellan nätverkskontrollern och varje Hyper-V värd

På en Hyper-V-värd kör du följande cmdletar för att kontrollera att HostID motsvarar instans-ID för en serverresurs på nätverkskontrollören.

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1
Properties       : Microsoft.Windows.NetworkController.ServerProperties

Reparation

Om du använder SDNExpress-skript eller manuell distribution uppdaterar du HostId-nyckeln i registret så att den matchar serverresursens instans-ID. Starta om värdagenten för nätverksstyrenheten på Hyper-V värd (fysisk server) Om du använder VMM tar du bort Hyper-V-servern från VMM och tar bort HostId-registernyckeln. Lägg sedan till servern via VMM igen.

Kontrollera att tumavtrycken för X.509-certifikaten som används av Hyper-V-värden (värdnamnet är certifikatets ämnesnamn) för sydgående kommunikation mellan Hyper-V-värden (NC Host Agent-tjänsten) och nätverksstyrenhetsnoderna är desamma. Kontrollera också att nätverksstyrenhetens REST-certifikat har ämnesnamnet CN=<FQDN or IP>.

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

Du kan också kontrollera följande parametrar för varje certifikat för att kontrollera att ämnesnamnet är vad som förväntas (värdnamn eller NC REST FQDN eller IP), certifikatet har ännu inte upphört att gälla och att alla certifikatutfärdare i certifikatkedjan ingår i den betrodda rotutfärdaren.

  • Ämnesnamn
  • Utgångsdatum
  • Betrodd av rotcertifikatutfärdare

Om flera certifikat har samma ämnesnamn på Hyper-V-värden väljer nätverkskontrollens värdagent slumpmässigt en som ska presenteras för nätverkskontrollen. Detta kanske inte matchar tumavtrycket för serverresursen som är känd av nätverksstyrenheten. I det här fallet tar du bort ett av certifikaten med samma ämnesnamn på Hyper-V-värden och startar sedan om värdagenttjänsten för nätverksstyrenheten. Om det fortfarande inte går att upprätta en anslutning tar du bort det andra certifikatet med samma ämnesnamn på Hyper-V-värden och tar bort motsvarande serverresurs i VMM. Återskapa sedan serverresursen i VMM, som genererar ett nytt X.509-certifikat och installerar det på Hyper-V-värden.

Kontrollera SLB-konfigurationstillståndet

SLB-konfigurationstillståndet kan fastställas som en del av de resultat som kommer från cmdleten Debug-NetworkController. Den här cmdleten visar också den aktuella uppsättningen nätverksstyrenhetsresurser i JSON-filer, alla IP-konfigurationer från varje Hyper-V värd (server) och lokal nätverksprincip från värdagentdatabastabeller.

Som standard samlas mMore-spårningar in. Om du inte vill samla in spårningar lägger du till parametern -IncludeTraces:$false .

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

Anmärkning

Standardutdataplatsen är <katalogen working_directory>\NCDiagnostics\. Standardutdatakatalogen kan ändras med hjälp av parametern -OutputDirectory .

Informationen om SLB-konfigurationstillstånd finns i filen diagnostics-slbstateResults.Json i den här katalogen.

Den här JSON-filen kan delas upp i följande avsnitt:

  • Väv
    • SlbmVips – Det här avsnittet visar IP-adressen för SLB Manager VIP, som används av Network Controller för att samordna konfiguration och hälsostatus mellan SLB Muxes och SLB Host Agents.
    • MuxState – Det här avsnittet visar en lista över ett värde för varje SLB Mux som distribueras, vilket ger tillståndet för mux
    • Routerkonfiguration – Det här avsnittet visar den överordnade routerns (BGP Peer) autonoma systemnummer (ASN), överförings-IP-adress och ID. Den visar även SLB Muxes ASN och Transit IP.
    • Ansluten värdinformation – I det här avsnittet visas hanterings-IP-adressen för alla Hyper-V värdar som är tillgängliga för körning av belastningsutjämningsarbetsbelastningar.
    • Vip Ranges – I det här avsnittet visas de offentliga och privata IP-poolintervallen för VIP. SLBM VIP ingår som en allokerad IP-adress från något av dessa intervall.
    • Mux Routes – I det här avsnittet visas ett värde för varje SLB Mux som distribueras som innehåller alla routningsannonser för just den muxen.
  • Hyresgäst
    • VipConsolidatedState – I det här avsnittet visas anslutningstillståndet för varje Tenant-VIP, inklusive annonserade routerprefix, Hyper-V-värd och DIP-slutpunkter.

Anmärkning

SLB-tillstånd kan fastställas direkt med hjälp av DumpSlbRestState-skriptet som är tillgängligt på Microsoft SDN GitHub-lagringsplatsen.

Gatewayverifiering

Från nätverksstyrenheten:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Från den virtuella gatewaydatorn:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

Uppifrån rackväxeln (ToR):

sh ip bgp summary (for 3rd party BGP Routers)

Windows BGP-router:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Förutom dessa, av de problem vi har sett hittills (särskilt på SDNExpress-baserade distributioner), verkar den vanligaste orsaken till att klientavdelningen inte konfigureras på GW-virtuella datorer vara det faktum att GW-kapaciteten i FabricConfig.psd1 är mindre jämfört med vad man försöker tilldela till nätverksanslutningarna (S2S-tunnlar) i TenantConfig.psd1. Detta kan kontrolleras enkelt genom att jämföra utdata från följande cmdletar:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Värd] Verifiera Dataplan

När nätverksstyrenheten har distribuerats, virtuella hyresgästnätverk och undernät har skapats och virtuella datorer har kopplats till de virtuella undernäten kan hosting-leverantören utföra ytterligare tester på nätvävsnivå för att kontrollera hyresgästens anslutning.

Kontrollera HNV-providerns logiska nätverksanslutning

När den första gäst-VM som körs på en Hyper-V-värd har anslutits till ett tenantnätverk tilldelar nätverkskontrollanten två HNV Provider IP-adresser (PA IP-adresser) till Hyper-V-värden. Dessa IP-adresser kommer från det logiska HNV-providernätverkets IP-pool och nätverksstyrenheten hanterar dem. Kör följande cmdlet för att ta reda på vad dessa två HNV IP-adresser är:

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Dessa HNV-provider IP-adresser (PA IP) tilldelas Ethernet-adaptrar som har skapats i ett separat TCPIP-nätverkssegment och har ett adapternamn VLANX, där X är den VLAN som tilldelats det logiska HNV-provider-nätverket (transport).

Anslutning mellan två Hyper-V värdar som använder det logiska HNV-providernätverket kan göras med en ping med en extra fackparameter (-c Y) där Y är TCPIP-nätverksfacket där PAhostVNICs skapas. Du kan ta reda på det här facket genom att köra följande kommando i en Windows-kommandotolk:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

Anmärkning

Pa-värdens virtuella nätverkskort används inte i datavägen och har därför ingen IP-adress tilldelad till vEthernet-kortet (PAhostVNic).

Anta till exempel att Hyper-V värdar 1 och 2 har IP-adresser för HNV-provider (PA) för:

Hyper-V värd PA IP-adress 1 PA IP-adress 2
Värd 1 10.10.182.64 10.10.182.65
Värd 2 10.10.182.66 10.10.182.67

Vi kan pinga mellan de två med hjälp av följande kommando för att kontrollera HNV-providerns logiska nätverksanslutning.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Reparation

Om ping för HNV-providern inte fungerar kontrollerar du din fysiska nätverksanslutning, inklusive VLAN-konfiguration. De fysiska nätverkskorten på varje Hyper-V värd bör vara i trunkläge utan någon specifik VLAN tilldelad. Det virtuella nätverkskortet (vNIC) för värd för hantering ska isoleras till det logiska hanteringsnätverkets VLAN.

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

Kontrollera stöd för MTU och jumboramar i HNV-providerns logiska nätverk

Ett annat vanligt problem i det logiska HNV-providernätverket är att de fysiska nätverksportarna och/eller Ethernet-kortet inte har en tillräckligt stor MTU konfigurerad för att hantera omkostnaderna från VXLAN-inkapslingen (eller NVGRE).

Anmärkning

Vissa Ethernet-kort och drivrutiner stöder det nya *EncapOverhead nyckelordet, som nätverksstyrenhetens värdagent automatiskt anger till värdet 160. Det här värdet läggs sedan till i värdet för nyckelordet *JumboPacket vars sammanfattning används som den annonserade MTU:en.

Till exempel *EncapOverhead = 160 och *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

Om du vill testa om det logiska HNV-providernätverket stöder den större MTU-storleken från slutpunkt till slutpunkt använder du cmdleten Test-LogicalNetworkSupportsJumboPacket :

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

Reparation

  • Justera MTU-storleken på de fysiska växelportarna till minst 1674B (inklusive 14B Ethernet-huvud och släpvagn)
  • Om ditt NIC-kort inte stöder nyckelordet EncapOverhead justerar du nyckelordet JumboPacket till minst 1674B

Kontrollera NIC-anslutningen för den virtuella klientdatorn

Varje vm-nätverkskort som tilldelats en virtuell gästdator har en CA-PA mappning mellan den privata kundadressen (CA) och HNV-providerns adressutrymme (PA). Dessa mappningar sparas i OVSDB-servertabellerna på varje Hyper-V värd och kan hittas genom att köra följande cmdlet.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

Anmärkning

Om de CA-PA-mappningar som du förväntar dig inte visas för en given hyresgäst-VM, kontrollerar du VM-nätverkskortet och IP-konfigurationsresurserna på nätverksstyrenheten med hjälp av cmdleten Get-NetworkControllerNetworkInterface. Kontrollera också de etablerade anslutningarna mellan NC-värdagentens nod och nätverkskontrollernoderna.

Med den här informationen kan Hoster initiera en ping för en virtuell klientdator från nätverksstyrenheten med hjälp av cmdleten Test-VirtualNetworkConnection .

Specifika felsökningsscenarier

Följande avsnitt innehåller vägledning för felsökning av specifika scenarier.

Ingen nätverksanslutning mellan två virtuella klientdatorer

  1. [Hyresgäst] Kontrollera att Windows-brandväggen på hyresgästernas virtuella datorer inte blockerar trafik.
  2. [Klient] Kontrollera att IP-adresserna är till den virtuella klientdatorn genom att köra ipconfig.
  3. [Värd] Kör Test-VirtualNetworkConnection från Hyper-V-värden för att verifiera anslutningen mellan de två virtuella klientdatorerna i fråga.

Anmärkning

VSID refererar till det virtuella undernätets ID. När det gäller VXLAN är detta VXLAN Network Identifier (VNI). Du hittar det här värdet genom att köra cmdleten Get-PACAMapping .

Example

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Skapa CA-ping mellan "Green Web VM 1" med SenderCA IP-adress 192.168.1.4 på värden "sa18n30-2.sa18.nttest.microsoft.com" med Mgmt IP-adress 10.127.132.153 till ListenerCA med IP-adress 192.168.1.5, som är båda kopplade till virtuellt undernät (VSID) 4114.

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[Klient] Kontrollera att det inte finns några distribuerade brandväggsprinciper angivna i det virtuella undernätet eller vm-nätverksgränssnitt som blockerar trafiken.

Fråga nätverksstyrenhetens REST-API som finns i demo-miljön på sa18n30nc i sa18.nttest.microsoft.com-domänen.

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Titta på IP-konfiguration och virtuella undernät som refererar till den här ACL:en

  1. [Värd] Kör Get-ProviderAddress på båda de Hyper-V värdar som är värdar för de två virtuella klientdatorerna i fråga. Kör sedan Test-LogicalNetworkConnection eller ping -c <compartment> från Hyper-V-värden för att verifiera anslutningen i det logiska HNV-providernätverket.
  2. [Värd] Kontrollera att MTU-inställningarna är korrekta på de Hyper-V värdarna och alla Layer-2-växlingsenheter mellan Hyper-V-värdarna. Kör Test-EncapOverheadValue på alla Hyper-V värdar i fråga. Kontrollera också att alla Layer-2 switches som finns mellan har MTU inställt på minst 1 674 byte för att ta hänsyn till maximala överhead på 160 byte.
  3. [Värd] Om PA IP-adresser inte finns och/eller CA-anslutningen är bruten kontrollerar du att nätverksprincipen har tagits emot. Kör Get-PACAMapping för att se om inkapslingsreglerna och CA-PA mappningar som krävs för att skapa virtuella överläggsnätverk är korrekt etablerade.
  4. [Värd] Kontrollera att nätverksstyrenhetens värdagent är ansluten till nätverksstyrenheten. Gör detta genom att köra netstat -anp tcp |findstr 6640.
  5. [Värd] Kontrollera att värd-ID:t i HKLM/ matchar instans-ID:t för de serverresurser som är värdar för de virtuella klientdatorerna.
  6. Hoster Kontrollera att portprofil-ID:t matchar instans-ID:t för nätverksgränssnitten för hyresgästens virtuella maskiner.

Loggning, spårning och avancerad diagnostik

Följande avsnitt innehåller information om avancerad diagnostik, loggning och spårning.

Centraliserad loggning av nätverksstyrenhet

Nätverksstyrenheten kan automatiskt samla in felsökningsloggar och lagra dem på en central plats. Logginsamling kan aktiveras när du distribuerar nätverksstyrenheten för första gången eller när som helst senare. Loggarna samlas in från nätverksstyrenheten och nätverkselement som hanteras av nätverksstyrenheten: värddatorer, programvarulastbalanserare (SLB) och gatewaydatorer.

Dessa loggar omfattar felsökningsloggar för nätverksstyrenhetsklustret, programmet Nätverksstyrenhet, gatewayloggar, SLB, virtuella nätverk och den distribuerade brandväggen. När en ny värd/SLB/gateway läggs till i nätverksstyrenheten startas loggningen på dessa datorer. På samma sätt stoppas loggning på dessa datorer när en värd/SLB/gateway tas bort från nätverksstyrenheten.

Aktivera loggning

Loggning aktiveras automatiskt när du installerar nätverksstyrenhetsklustret med hjälp av cmdleten Install-NetworkControllerCluster . Som standard samlas loggarna in lokalt på noderna för nätverksstyrenheten på %systemdrive%\SDNDiagnostics. Vi rekommenderar att du ändrar den här platsen till en fjärrfilsdelning (inte lokal).

Klusterloggarna för nätverksstyrenheten lagras på %programData%\Windows Fabric\log\Traces. Du kan ange en central plats för loggsamlingen med parametern DiagnosticLogLocation . Den här platsen bör också vara en fjärrfildelning.

Om du vill begränsa åtkomsten till den här platsen kan du ange autentiseringsuppgifterna för åtkomst med parametern LogLocationCredential . Om du anger autentiseringsuppgifterna för att komma åt loggplatsen bör du även ange parametern CredentialEncryptionCertificate som används för att kryptera autentiseringsuppgifterna som lagras lokalt på noderna för nätverksstyrenheten.

Med standardinställningarna rekommenderar vi att du har minst 75 GB ledigt utrymme på den centrala platsen och 25 GB på de lokala noderna (om du inte använder en central plats) för ett nätverksstyrenhetskluster med tre noder.

Ändra loggningsinställningar

Du kan när som helst ändra loggningsinställningarna med hjälp av cmdleten Set-NetworkControllerDiagnostic . Följande inställningar kan ändras:

  • Centraliserad loggplats.

    Du kan ändra platsen för att lagra alla loggar med parametern DiagnosticLogLocation .

  • Autentiseringsuppgifter för att komma åt loggplatsen.

    Du kan ändra autentiseringsuppgifterna för att komma åt loggplatsen med parametern LogLocationCredential .

  • Flytta till lokal loggning.

    Om du har angett en central plats för att lagra loggar kan du gå tillbaka till loggning lokalt på nätverksstyrenhetsnoderna med parametern UseLocalLogLocation (rekommenderas inte på grund av stora diskutrymmeskrav).

  • Loggningsomfång.

    Som standard samlas alla loggar in. Du kan ändra omfånget så att endast nätverksstyrenhetsklusterloggar samlas in.

  • Loggningsnivå.

    Standardloggningsnivån är Informational. Du kan ändra den till Fel, Varning eller Utförlig.

  • Loggens åldrandetid.

    Loggarna lagras på ett cirkulärt sätt. Du har tre dagars loggningsdata som standard, oavsett om du använder lokal loggning eller centraliserad loggning. Du kan ändra den här tidsgränsen med parametern LogTimeLimitInDays .

  • Storlek på loggens åldrande.

    Som standard har du högst 75 GB loggningsdata om du använder centraliserad loggning och 25 GB om du använder lokal loggning. Du kan ändra den här gränsen med parametern LogSizeLimitInMBs .

Samla in loggar och spårningar

VMM-distributioner använder centraliserad loggning för nätverksstyrenheten som standard. Platsen för filresursdelning för dessa loggar anges när du distribuerar tjänstmallen för Nätverkskontrollern.

Om du inte anger någon filplats sparar varje nätverksstyrenhetsnod loggar lokalt. Varje nod sparar loggar under C:\Windows\tracing\SDNDiagnostics. Dessa loggar sparas med hjälp av följande hierarki:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Spårningar

Nätverksstyrenheten använder (Azure) Service Fabric. Service Fabric-loggar kan krävas vid felsökning av vissa problem. Dessa loggar finns på varje nod för nätverksstyrenheten i C:\ProgramData\Microsoft\Service Fabric.

Om en användare har kört cmdleten Debug-NetworkController blir fler loggar tillgängliga på varje Hyper-V värd, som har angetts med en serverresurs i nätverksstyrenheten. Dessa loggar (och spårningar om de är aktiverade) sparas under C:\NCDiagnostics.

SLB-diagnostik

SLBM-fabri↑serfel (åtgärder från värdtjänstleverantören)

  1. Kontrollera att Software Load Balancer Manager (SLBM) fungerar och att orkestreringsskikten kan kommunicera med varandra: SLBM –> SLB Mux och SLBM –> SLB-värdagenter. Kör DumpSlbRestState från valfri nod med åtkomst till REST-slutpunkten för nätverksstyrenheten.
  2. Verifiera SDNSLBMPerfCounters i PerfMon på en av de virtuella datorerna för nätverksstyrenhetsnoden (helst den primära noden för nätverksstyrenheten – Get-NetworkControllerReplica):
    1. Är Load Balancer-motorn (LB) ansluten till SLBM? (SLBM LBEngine-konfigurationer totalt > 0)
    2. Känner SLBM åtminstone till sina egna slutpunkter? (VIP-slutpunkter totalt>= 2)
    3. Är Hyper-V värdar (DIP) anslutna till SLBM? (HP-klienter anslutna == antal servrar)
    4. Är SLBM anslutet till Muxes? (Muxar Anslutna == Muxar Friska på SLBM == Muxar rapporterar frisk = # SLB Muxar VM:er).
  3. Kontrollera att den konfigurerade BGP-routern framgångsrikt är peering med SLB MUX.
    1. Om du använder RRAS med fjärråtkomst (d.v.s. virtuell BGP-dator):
      1. Get-BgpPeer ska visa ansluten.
      2. Get-BgpRouteInformation bör visa minst en rutt för SLBM:ens egna VIP.
    2. Om du planerar att använda den fysiska ToR-switch (Top-of-Rack) som BGP-peer, konsultera dokumentationen:
      1. Till exempel: # show bgp instance
  4. Verifiera räknare för SlbMuxPerfCounters och SLBMUX i PerfMon på den virtuella SLB Mux-datorn.
  5. Kontrollera konfigurationstillstånd och VIP-intervall i Software Load Balancer Manager-resursen.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (Kontrollera VIP-intervall i IP-pooler och se till att SLBM self-VIP (LoadBalanacerManagerIPAddress) och eventuella klientriktade VIP:er finns inom dessa intervall)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

Om någon av kontrollerna ovan misslyckas, kommer hyresgästens SLB-status också att vara i ett felläge.

Reparation

Åtgärda följande baserat på följande diagnostikinformation:

  • Kontrollera att SLB Multiplexers är anslutna
    • Åtgärda certifikatproblem
    • Åtgärda problem med nätverksanslutning
  • Kontrollera att BGP-peeringinformation är korrekt konfigurerad
  • Se till att värd-ID i registret matchar serverinstans-ID i serverresursen (referensbilaga för HostNotConnected-felkod )
  • Samla in loggar

SLBM-klientfel (värdtjänstprovider och klientåtgärder)

  1. [Värd] Kontrollera Debug-NetworkControllerConfigurationState om några LoadBalancer-resurser är i ett feltillstånd. Försök att minimera genom att följa tabellen Åtgärdsobjekt i tillägget.
    1. Kontrollera att det finns en VIP-slutpunkt och annonseringsvägar.
    2. Kontrollera hur många DIP-slutpunkter som har identifierats för VIP-slutpunkten.
  2. [Klient] Verifiera att lastbalanserarens resurser har angetts korrekt.
    1. Verifiera att DIP-slutpunkter som är registrerade i SLBM är värdar för virtuella klientdatorer, vilket motsvarar IP-konfigurationerna för LoadBalancer-serverdelsadresspoolen.
  3. [Värd] Om DIP-slutpunkter inte identifieras eller ansluts:

    1. Kontrollera Debug-NetworkControllerConfigurationState

      Kontrollera att NC- och SLB-värdagenten är anslutna till nätverksstyrenhetens händelsekoordinator med hjälp av netstat -anp tcp |findstr 6640).

    2. Kontrollera HostIdin nchostagent tjänstens registernyckel (referens till felkod HostNotConnected i bilagan) matchar motsvarande serverresursens instans-ID (Get-NCServer |convertto-json -depth 8).

    3. Kontrollera att portprofil-ID för den virtuella datorns port matchar motsvarande nätverksgränssnittets resurs instansens ID.

  4. [Värdleverantör] Samlar in loggar.

SLB Mux-spårning

Information från Software Load Balancer Muxes kan också fastställas via Händelsevisaren.

  1. Välj Visa analys- och felsökningsloggar under menyn Visning av loggboken.
  2. Gå till Program- och tjänstloggar>Microsoft>Windows>SlbMuxDriver>Trace i Händelsevyn.
  3. Högerklicka på den och välj Aktivera logg.

Anmärkning

Vi rekommenderar att du bara har den här loggningen aktiverad under en kort tid medan du försöker återskapa ett problem.

VFP- och vSwitch-spårning

Från alla Hyper-V värd som är värd för en virtuell gästdator som är ansluten till ett virtuellt klientnätverk kan du samla in en VFP-spårning för att avgöra var problemen kan ligga.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes
  • Last updated on